Development Challenges

Application Development in the New MIllennium
Today, the Internet has made it possible to create a new breed of distributed, dynamic applications that embody several strategically important characteristics:

• Market-Facing / Self-Service - Where previous generations of business systems have focused on automating internal, paper-intensive processes like payroll or accounting, today, businesses are giving customers and partners a self-service window on the Web. For example, customers can enter their own eCommerce orders, or partners can check the status of shipments.
• Elective, Not Mandatory - Internal-automation applications (such as payroll, manufacturing, or finance) are used by employees. As a result, usage of these systems is a requirement that can be enforced by the employer. With customers, however, usage of business systems is elective rather than mandatory. Customers have no such constraints or obligations to learn your way of doing business. If they don't like your application, they can choose not to use it by doing business with your competitor.
• Merge Content and Transactions - Dynamic Internet applications combine rich content (JPEGs, unstructured text, or rich media, for example) with structured information from transactional systems.
• Linkage to Product and Distribution Systems - In this new context for applications, customers are buying not only products, but the surrounding business systems that support that product. For example, the majority of an online brokerage's product is the business application it provides - not the actual buying and selling of securities.
• Multi-Disciplinary Teams - Today's development teams include not only coding experts, but also business analysts and functional experts who drive the design of the applications.
• Wide Accessibility - Dynamic applications use the Internet to provide worldwide accessibility at a very low cost from a variety of thin-client devices.
• High Availability - Given their public-facing nature, today's Internet applications must provide high degrees of fault tolerance and availability. Downtime isn't an option for these systems.
• High Adaptability - Business applications in the new millennium must be "change-friendly" to stay in step with highly fluctuating environments as companies respond more nimbly to competitive pressures and customer-specific requirements

The Emergence of the N-Tier Application Architecture
Unlike simple two-tier client/server architectures, an n-tier architecture provides a middle tier, where any number of application servers are distributed across the network, to manage client sessions, host business logic, and connects to back-end resources for data, transactions, and content. This provides the platform for thin-client applications that expand portability of and accessibility to applications.

The Java™ Platform
Java is the pre-eminent platform of eBusiness. Specifically, the Java 2 platform is the definitive environment for enterprises aiming to build and install dynamic Internet applications that can run on a variety of computers, servers and other computing devices. Java 2 provides developers with speed, security and functionality that make it easier to create interoperable, mission-critical enterprise applications. The Java 2 platform is widely supported by the industry, and is being endorsed by hundreds of industry-leading companies worldwide.

The Java 2 Standard Edition (J2SE) is targeted at graphical application developers who are building and deploying visual, network-centric enterprise applications to be deployed from desktop PCs to workgroup servers. The Java 2 Enterprise Edition (J2EE) is targeted at the integration, at the business logic level, of enterprise applications and services and delivering them in new ways to HTML and XML clients.

Component-Based Development
The most important force in application development today is the movement toward building applications by assembling discrete components. Components are small pieces of software that encapsulate business rules and application functionality for an express purpose. Components share several common characteristics:

• They can be modules within larger systems
• They are defined by standard interfaces
• They are typically developed and executed independently
• They can communicate with other components
• They are the building blocks of larger applications

Developers can assemble and reuse components in a mix-and-match style that dramatically improves developer productivity. Component-based development uses a set of technologies and tools to enable the construction of applications from new and pre-fabricated components. Component-based development is the critical requirement for n-tier, dynamic Internet applications. Component development models simplify construction of an enterprise architecture in several ways by enabling:

• Construction, assembly, and maintenance of enterprise components
• Integration of legacy applications - including commercial systems - for execution as large components
• Deployment of tools that enable new deployment models that accommodate networked architectures - including the Internet
• Use of off-the-shelf components in corporate application

Component-based development embodies a vision of the "software factory," complete with pre-built components, subassemblies, and final assembly. As a result, productivity, speed of development, and product quality all soar. Without component-based development, those goals are not feasible.

In a component-based development model, we move away from the large, monolithic application to a modular application that is easy to build and maintain. Development teams can buy best-of-breed components and customize and tailor them as needed. Building new components is the last resort.

Unfortunately, component-based development has carried with it an inherent paradox. The more fine grained or simple the component is, the lower the developer's productivity is. Working with a class library, for example, the developer's productivity is low, while, it increases dramatically as the component gets more large grained or complex . But as the component becomes more complex or larger grained (and developer productivity grows), its reusability typically decreases. Large robust applications - which are really or should be large, complex "super-components" - are typically not reusable in the way that finely granular components would be. This is because as a component becomes more complex its functionality becomes more specific to particular applications. Accordingly, reuse within other applications generally requires modification to some or all of its functionality. Until now, Technologies have simply not been available to enable customization without a total rewrite.

Reusability: The Ultimate Benefit of Component-Based Development
For many years, developers have sought a way to avoid reinventing the wheel with each development project they undertake. Application development using standards-based components offers the promise of reusability and its high-value benefits:

• Faster Time-to-Market - Pre-fabricated components slash development times by giving developers a wealth of code from which to start. As libraries of standard
  components become widely available, developers will have more resources at their disposal to jump-start development efforts.
• Higher-Quality Software - With reuse, applications are created with proven, tested components. Not only does that reduce testing problems, it simultaneously
  ensures a higher-quality application.
• Business-Rule Enforcement - By reusing components, development teams also reuse the approved business rules they contain.
• Easier Maintenance - Developers can swap-out components without taking down the entire system

Productivity: The Ultimate Benefits of Reusability
Perhaps the greatest benefit of reusable components is the leveraged productivity it provides development teams. Typically, the finer (more granular) a component is, the more reusable it is. Consider, for example, a simple class library. It is used numerous times within a single application; however, because it is so granular - such a small portion of the overall system, there are few productivity gains to be achieved. Conversely, as the component grows in size - and specificity - it is reused rarely. On those occasions, however, where this larger, special-purpose component is required, developer productivity is dramatically higher. The holy grail for development teams is to merge these curves so that reusability is high, regardless of the complexity of the component.

Component-Based Development: From Concept to Implementation
The time is ripe for organizations to implement strategic component-based development plans. There is opportunity to take advantage of the component benefits; however, there are still challenges to be faced:

• Incompatible Component Standards - Components come from a variety of sources with a variety of interfaces. That means developers must be experts in a wide range of proprietary tools and environments for customization and assembly. However, the Java 2 platform provides the needed industry standards and platform interoperability.
• Monolithic Architectures - Previous generations of business applications were large, vertically integrated monoliths that tied business logic to presentation and data. Internet-based n-tier architectures enable and promote application partitioning and distribution.
• Commercial Application Customization - One of the thorny challenges facing corporate development teams today is the customization of commercial software to adapt to the unique requirements of the business. Typically, this "breaks" the relationship with the commercial software vendor and makes future upgrades unfeasible. Components enable corporate developers to "wrap" commercial applications with "extension layers" that customize commercial applications without changing the underlying code - and preserving upgrade/warranty paths.
• The Skills Gap - Given that the Java platform is ideal for component-based development, businesses are scrambling for the relatively few knowledgeable Java programmers to build or adapt their components. Most development teams have a skills gap in this area.

It was with these challenges in mind that the LiveWater Component Design Center was developed. LiveWater's goal is to enable organizations to implement their strategic component-based development plans by addressing these issues.

LiveWater | Development Challenges | Introducing LiveWater | Unique Technologies | LiveWater Benefits

For more information, visit LiveWater's web site at www.livewater.com. Or, you can email us at info@livewater.com.

⌐ 2000 LiveWater, Inc.. All rights reserved. LiveWater is a trademark of LiveWater, Inc. All other trademarks or registered trademarks are property of their respective holders.